@mreid-tt this includes a proposal to distinguish active an inactive packages.

It is still a static solution and does not add a user filter to include/exclude inactive packages.

@hgy59, great work! Pulled into my test environment and all the improvements seem to be there as described. 🚀

I've not interrogated the modifications you did to the tests but I will be guided by your validation.

I've not interrogated the modifications you did to the tests but I will be guided by your validation.

packages frontend test changes:

• beta labels are not shown anymore
• packages with only inactive versions are shown now

package (singular) frontend test changes:

• beta label tests added (according to former packages tests)

This are the updated views:

beta on verstion instead of package (revisions 10 and 11 are beta, rev 9 not):

inactive package with tooltip (ppc824x and ppc854x of rev 3 are inactive), active packages have green label now (screen shot without mouse cursor):

This are the updated views:

I was thinking more about the tests. Is there a way for it to test that the builds that are shown in the package webpage have the active/inactive colours you added? I don't recall seeing that in your new tests.

Hello @hgy59, I encountered a situation while working on the admin side that I believe you can address on the frontend and incorporate into this pull request. The issue arises when a package is created without any versions, and upon manually navigating to the package URL, the server returns an internal server error. I propose the following code modification to handle this scenario:

Change to:

    if package is None or not package.versions:

Hi @hgy59, as another suggestion I would remove the duplicate password reset link on the login page by deleting this line:

@hgy59, I'd love to hear your thoughts on my suggestions. Alternatively, if you prefer, I can make the amendments directly through a commit for you.

@hgy59, I hope you don't mind but I reverted a change to spkrepo/views/admin.py as this was addressed in my PR #112. This will prevent a merge conflict between the two.

@Diaoul, @publicarray, do either of you have time to give this a review and approval? Eager to get these into production.

I was looking at issue #116 that was raised regarding the webpage footer. In looking at the code and the website they do not seem to be in sync. For example the footer in the source code is:

However on the website the footer has this code:

    <footer class="footer" role="contentinfo">
      <div class="container">
        <p>Designed by Antoine Bertin.</p>
        <p>Maintained by <a href="https://github.com/SynoCommunity?tab=members">SynoCommunity</a> with the help of <a href="https://github.com/SynoCommunity/spksrc/graphs/contributors">contributors</a>.</p>
        <p>Code licensed under <a href="https://github.com/SynoCommunity/spkrepo/blob/master/LICENSE" target="_blank">MIT</a>.</p>
      </div>
    </footer>

I would have normally proposed a fix to include in this PR but the codebase and the website don't seem to align. Any thoughts on this? @publicarray @Diaoul ?

Yes some templates are overridden locally on the server. The only way to change them is to SSH to it.

Yes some templates are overridden locally on the server. The only way to change them is to SSH to it.

Hmm, any particular reason for this manual editing? Should I move the server-side HTML into the codebase so they can be in sync?

@hgy59 given the comment above from @Diaoul, I've brought the code in from the live website into the codebase so they would be in sync and resolved the broken members link raised in #116.

I wonder if @Diaoul expects to include synocommunity.com specific templates into code base, as spkrepo may be deployed by other users.

I wonder if @Diaoul expects to include synocommunity.com specific templates into code base, as spkrepo may be deployed by other users.

As far as I can observe the code is very explicit to SynoCommunity in the templates. My suspicion is that there was a minor HTML change in the footer that was needed sometime ago and the change was made as a direct edit on the server and never brought back into the codebase (I've seen a similar thing in the database schema). This last commit was meant to bring them back in sync so that we don't have this to worry about it moving forward.

To check for any others (that we can't see without server access), according to this blog we can run these commands on the server:

To display file names that are NOT under version control:

git clean -fdxn

To display all changes in the GIT files just use:

git diff .

So if there are any other files which are different we can sync them up. This makes the server easier to maintain and if we ever had to move to another server there would be less non-standard variables to worry about.

@mreid-tt looks good to me, with this the spkrepo is going to be more specific for our use case and no longer as generic.

The reason for removing the password reset I assume is because we can't send emails? I would have thought it's best to leave it in regardless so that at least a reset code can be generated, even if it isn't sent.

Hi @hgy59, as another suggestion I would remove the duplicate password reset link on the login page by deleting this line:

spkrepo/spkrepo/templates/security/login_user.html

Line 6 in 0ce2d02

<p><a href="{{ url_for('security.forgot_password') }}">I forgot my password</a></p>

Oh duplicate I see